Red-Green-Refactor Cycle

There is a well-known diagram that explains how to apply TDD practically – it’s known as the red-green-refactor cycle (Figure 1-1).

A Closer Look at Red-Green-Refactor

Figure 1-2 takes a closer look at the process.

Traditionally, TDD contains two parts: quick implementation and refactoring. In practice, the tests for quick implementation are not limited to the unit tests. They can be the acceptance tests as well – these are higher-level tests that focus more on business value and the end-user journey, without worrying too much about the technical details. Implementing the acceptance tests first could be an even better idea.

Starting with acceptance tests ensures that the right things are prioritized, and it provides confidence to developers when they want to clean up and refactor the code in the later stage. Acceptance tests are intended to be written from the end user’s perspective; a passing acceptance test ensures the code meets the business requirement. Additionally, it can protect the developer from wasting time on false assumptions or invalid requirements.

There is a principle in Extreme Programming known as YAGNI, or you aren’t gonna need it. YAGNI can be very useful for protecting developers from wasting their valuable time. Developers are very good at making assumptions around potential requirement changes, and based on those assumptions, they may come up with some unnecessary abstractions or optimizations that can make the code more generic or reusable. The problem is that those assumptions rarely turn out to be true. YAGNI emphasizes that you should not do it until you have to.

However, in the refactor phase, you can implement those abstractions and optimizations. Since you already have test coverage, it’s much safer to do the cleanup then. Small refactors such as modifying a class name, extracting a method, or extracting some classes to a higher level – anything that helps to make the code more generic and SOLID – are now safer and easier to undertake.

Types of TDD

TDD is a big yet mixed concept. It has many variations and different schools, such as UTDD, BDD, ATDD, and so on. Traditionally, TDD implied Unit Test-Driven Development or UTDD. However, the TDD we are discussing in this book is ATDD (Acceptance Test-Driven Development), an extended version of the traditional concept, with an emphasis on writing the acceptance test from the business perspective and using it to drive out production code.

Having various tests in different layers can ensure that we are always on the right track and have the correct functionality.

Acceptance Test-Driven Development

In short, ATDD describes the behavior of the software from the end user’s point of view, focusing on the business value of the application, rather than implementation details. Instead of verifying functions being called at certain times with correct parameters, it makes sure that when a user places an order, they receive their delivery on time.

We can merge the ATDD and UTDD into one diagram, as shown in Figure 1-3.

The diagram describes the following steps:

1. 1.

   Write an acceptance test and see it fail.

    
2. 2.

   Write a unit test and see it fail.

    
3. 3.

   Write code to make the unit test pass.

    
4. 4.

   Refactor the code.

    
5. 5.

   Repeat 2–4, until acceptance test passes.

    

When you look at this process closely, you find that during the development stage, the acceptance test could be failing for quite some time. The feedback loop turns out to be very long, and there is a risk that an always-failed test means no test (protection) at all. Developers could be confused about whether there are defects in the implementation, or whether there is any implementation at all.

To resolve this problem, you have to write acceptance tests in relatively small chunks, testing a tiny slice of the requirement at a time. Alternatively, you could use the fake it until you make it approach, as we are going to use across this book.

The steps remain the same; only an extra fake step is added:

1. 1.

   Write a failed acceptance test.

    
2. 2.

   Make it pass in the most straightforward way (a fake implementation).

    
3. 3.

   Refactor based on any code smells (like hard-coded data, magic number, etc.).

    
4. 4.

   Add a new test based on new requirement (if we need a new acceptance test, go back to step 1; otherwise, the process is just like traditional TDD).

    

Note that in the second step, you can use hard-coding or a snippet of static HTML to make the test pass. At first glance, that may look redundant, but you will see the power of fake in the next few chapters.

The benefit of this variation is that when a developer is refactoring, there is always a passing acceptance test protecting you from breaking existing business logic. The drawback of this approach is that when a developer doesn’t have enough experience, it can be difficult for them to come up with clean code designs – they could keep the fake in some way (e.g., a magic number, lack of abstractions, etc.).

Prerequisites of TDD

TDD has a strict and crucial prerequisite for developers: how to detect code smells and how to refactor them toward good design. For example, when you find some smelly code (e.g., lack of abstractions or magic numbers) and aren’t sure how to make it better, then TDD alone cannot help you. Even though you are forced to use the orthodox workflow of TDD, you could end up with some unmaintainable tests in addition to poor-quality code.

Tasking

Another critical skill required by TDD is splitting a large requirement into smaller chunks through tasking. I would suggest every developer should learn how to split requirements before they even start to write their first test.

When we pick up a task, when we start to think through or discuss all the details, we may soon find we’re trapped by a mountain of technical details and do not know where to start with. Our brain loves explicit and concrete things and hates abstraction – things that are invisible or implicit.

By utilizing some simple tools, we can make the work much more digestible for our brains, and tasking is one of these tools. It can help us divide a big task into smaller ones, which we can then tick off one after another.

For splitting a relatively big task into smaller pieces, a widely used principle is INVEST.

To-Do list with Post-it

Usually, we can stop at the second round of splitting, since the red-green-refactor is far too detailed in terms of tasking. And too granular tasks means more management effort (tracking those tasks needs more energy). To make the tasks visible, we can put it down on a post-it note and mark a simple tick once it’s done (Figure 1-4).

By using this simple tool, you can then focus on what you’re going to do and make the progress more accurate when you want to update it to other team members (e.g., in the daily stand-up meeting). By saying a task is 50% done, half of the items on the list are ticked off on the list you made earlier.

Install Node.js

Alternatively, if you are running a different operating system, or just want another option, node can be downloaded here.

Once you have it installed locally, you can then use npm (Node Package Manager) to install node packages – it’s a binary program shipped with the node runtime.

Install and Config Jest

Jest is a testing framework from Facebook that allows developers to write reliable and fast running tests in a more readable syntax. It can watch changes in test/source files and rerun the necessary tests automatically. This allows you to get quick feedback, and that is a crucial factor in TDD. The speed of feedback can even determine whether TDD works for you or not. Simply put, the faster tests can run, the more efficient developers can be.

After the installation, you can run jest --init to specify some default settings, such as where jest should find the test files and the source code, which environment (there are a lot) jest should run against (browser or node for the back end), and so on. You have to answer some questions to let jest understand your requirements; for now, let’s just accept all the default settings by saying Yes to all the questions.

  Configuration file created at /Users/juntaoqiu/learn/jest-101/jest.config.js

Basic Concepts in Jest

In this section, we’re about to go through some basic concepts in Jest. We use describe to define a test block. We can use that mechanism to arrange different test cases and gather relevant test cases together as a group.

Using ES6

By default, you can only use ES5 (a relatively old version of JavaScript) in node.js (interestingly, by the time I started to write this chapter, I cannot use most of the features in ES6 directly with node runtime by default). However, since we’re already in 2021, ES6 should be the default programming language you should choose for your front-end projects. Good news is that you don’t have to wait till all the browsers implement the specification; you can use babel to translate and compile the ES6 code into ES5.

Equality

toEqual and toBe may be the most common matchers you will find and use in almost every test case. As the name implies, they are used to assert whether values are equal to each other (the actual value and the expected value).

The last test will fail. For primitives like strings, numbers, and booleans, you can use toBe to test the equality. While for Objects, internally jest uses Object.is to check, which is strict and compares objects by memory address. So if you want to make sure all the fields are matching, use toEqual.

.not Method for Opposite Matching

Matchers for Array and Object

Jest also provides matchers for Array and Object .

The Powerful Function Expect

We have tasted the matcher a little bit in previous sections; let’s take a look at another super weapon Jest provided: the expect.

The variable givenName here is not a simple value; it’s a new matcher and matches strings containing Juntao.

It looks a bit strange at first glance, but once you understand it, that pattern would help you to build more complicated matchers.

For whatever reason, in our test, we don’t care about address at all. We do care if the name field contains Juntao and the project.name contains ThoughtWorks.

Build Your Matchers

Jest also allows you to extend the expect object to define your own matchers. In that way, you can enhance the default matcher set and make the test code more readable.

Let’s see a concrete example in this section. As you might know, jsonpath is a library that allows developers to play with a JavaScript object – similar to xpath in XML.

jest.fn for Spying

You can use jest.fn() to create a function that could be invoked just like other regular functions, except it provides the ability to be audited. A mock can track all the invocations to it. And it can record the invoke times and the parameter passed in for each invoke. That could be very useful, since in many scenarios, we just want to ensure the particular function has been called with specified parameters, and in the correct order – we don’t have to do the real invocation.

Mock Implementation

Instead of defining a static mock, you can define an implementation by yourself too. The real implementation could be very complicated; maybe it does some calculation based on a complex formula on some given parameters.

Stub a Remote Service Call

That is something very useful. Jest provides other mock mechanisms as well, but we are not going to discuss them here. We are not using any advanced features in this book other than what we have addressed earlier.

If you are interested, please check jest help or homepage for more information.

Using Given-When-Then to Arrange a Test

It’s usually described as Given, When, and Then or in the 3As format, where the As stands for Arrange, Act, and Assert. Both describe the same process.

In the Given clause, you describe all the preparation, including setting up dependencies. In When, you trigger the action or change the state of a subject to be tested, usually a function call with prepared parameters. Finally, in Then, you examine the result to see if it matches the expected result in some way (equals to something exactly, or contains particular patterns or throws an error, and so on).

Example: function addition

Imagine we are implementing a calculator with TDD. A test for addition could be a good starting point.

An Expression Parser for Tracking Progress

Looks pretty straightforward, right? Can’t wait to jump in and write the code? Hold on, let’s get started with a test first and get a feeling of how to apply TDD in such a case.

Applying TDD Step by Step

As we already have the tasks split, we then only need to translate them into corresponding unit test. Let's start with our first test.

Keep Refactoring – Extract Functions to Files

Nice and clean, right? As you can see in Figure 3-1, all the tests now are passing.

Note that the refactoring process can keep going until you feel comfortable with the code. Be careful not to over engineer it by putting too many assumptions around potential changes or abstracting the code to a level beyond what is helpful.

Feature 1 – Booklist

We can describe the user story in this form:

As a user I want to see a list of books So that I can learn something new

This is a very popular format to describe a user story, and there are good reasons for that. By describing As a <role>, it stresses who would benefit from this feature, and by saying I want to <do something>, you’re explaining how the user would interact with the system. Finally, So that <value> sentence describes the business value behind this feature.

This format forces us to think from the stakeholder’s perspective and hopefully tell both business analysts and developers what the most important (valuable) point is of the user story they are working on.

The given clause explains the current status of the application, when it means the user triggers some action, for example, clicks a button or navigates to a page, and then is an assertion that states the expected performance of the application.

Feature 2 – Book Detail

As a user, I want to see the details of a book So that I can quickly get an understanding of what it’s about.

Feature 3 – Searching

As a user, I want to search for a book by its name So that I can quickly find what I’m interested in.

Feature 4 – Reviews

As a user, I want to be able to add a review to a book I have read previously So that people who have the same interests could decide if it is worthwhile to read.

With all those requirements well defined, we can start with project setting up.

Using create-react-app

create-react-app will install react, react-dom, and a command-line tool named react-scripts by default. Moreover, it will download those libraries and their dependencies automatically, including webpack, babel, and others. By using create-react-app, we don’t need any config to get the application up and running.

There will be a new browser tab opened automatically at this address: http://localhost:3000. And the UI should look like Figure 4-2.

Project File Structure

We don’t need all of the files generated by create-react-app, so let’s do some clean up first. We can remove all the irrelevant files in src folder, leaving us with the following files:

src

├── App.css

├── App.js

├── index.css

└── index.js

Modify the App.js file content so it looks as follows:

 import React from 'react';

 import './App.css';

 function App() {

    return (

      <div className='App'>

        <h1>Hello world</h1>

      </div>

    );

 }

 export default App;

And the index.js like this:

import React from 'react';

import ReactDOM from 'react-dom';

import './index.css';

import App from './App';

ReactDOM.render(<App />, document.getElementById('root'));

Then our UI should look something like Figure 4-3.

Material-UI Library

To make the application we’re demonstrating here look more realistic, as well as reduce the css tricks in the code snippets, we will use Material-UI . This library contains many reusable components that are ready to be used out of the box, such as Tabs, ExpandablePanel, and others. It will help us to build our bookish app faster and more easily.

After that, let’s put some fonts in our public/index.html to improve the look and feel.

Cypress

In the first edition of this book, I used puppeteer as the engine for UI functional tests, and it’s a great tool for that purpose. However, I found its API is too low level from most beginners. From the end-user perspective, you have to remember a lot of unnecessary details such as async/await pairs when querying elements on the page. And it does not provide basic helpers, such as fixtures or stubs, which are widely used in TDD.

So this time, I will use Cypress instead – the idea is pretty much the same, Cypress gives us more options and better mechanisms to reduce the effort of writing tests. Features such as fixture and route are shipped with the tool that can make our life much easier.

The good news is that installation is simple, and you don’t have to configure it at all.

Setting Up Cypress

Let’s run the following command to start:

npm install cypress --save-dev

After the installation, make sure the app is running, and then we can run the cypress command to launch the GUI to create our first test suite as seen in Figure 4-4:

npx cypress open

This will create a new folder called cypress outside of our project code.

For now, let’s get rid of most of the generated code and create a file bookish.spec.js under the ui folder, which is under cypress/integration for our first end-to-end test. The folder structure should look like Figure 4-5.

For now, the only thing we need to care about is bookish.spec.js. We will examine fixtures in the coming chapters.

Writing Our First End-to-End Test

Do you remember when we talked about how the most challenging part of TDD might be where to start and how to write the very first test?

A feasible option for our first test could be

• Make sure there is a Heading element on the page, and the content is Bookish.

This test might look pointless at first glance, but actually, it can make sure that

• Front-end code can compile and translate.

• The browser can render our page correctly (without any script errors).

So, in our bookish.spec.js, simply put

describe('Bookish application', function() {

  it('Visits the bookish', function() {

    cy.visit('http://localhost:3000/');

    cy.get('h2[data-test="heading"]').contains('Bookish')

  })

})

cy is the global object in cypress. It contains almost everything we need to write tests: navigating to the browser, querying an element on the page, and doing the assertions. The test we just wrote is trying to visit http://localhost:3000/ and then make sure the h2 with data-test flag as heading has content equal to the string: Bookish (Figure 4-6).

In the daily development workflow, especially when there are several end-to-end tests running, you might not want to see all the details (fill out form fields, scroll the pages or some notifications), so you can configure it to run in headless mode with the following command:

npx cypress run

Define a Shortcut Command

Just define a new task under the scripts section in package.json:

"scripts": {

  "e2e": "cypress run"

},

Make sure the app is running (npm start), and then run npm run e2e from another terminal. This will do all the dirty work for you and give you a detailed report after all tests are complete (Figure 4-7).

As a bonus, you can use this command in the CI environment as well.

Commit Code to Version Control

Beautiful! We now have an acceptance test and its corresponding implementation, and we can commit the code to version control just in case we need to look back in the future. I’m going to use git in this book since it’s the most popular one, and you will find it installed in almost every developer’s computer nowadays.

A List (of Books)

Verify Book Name

Awesome! Our tests pass again (Figure 5-1).

Now it’s time to review the code to check if there are any code smells and then undertake any necessary refactoring.

Refactoring – Extract Function

Firstly, putting all the .book-item elements in the render method might not be ideal. Instead, we can use a forloop to generate the HTML content.

Note Review the extract function here, https://refactoring.com/catalog/extractFunction.html

Our tests are still passing. We improved our internal implementation without modifying the external behavior. This is a good demonstration of just one of the benefits TDD provides: easier and safer cleanup.

Refactoring – Extract Component

Now, the code is much more clean and compact, but it could be better. One possible change is to modularize the code further; the granularity of abstraction should be based on component, rather than on function. For instance, we are using the function renderBooks to render a parsed array as a book list, and we can abstract a component named BookList to do the same thing. Create a file BookList.js, and move the function renderBooks into it.

With this refactoring, our code becomes more declarative and also easier to understand. Additionally, our tests remain green. You can fearlessly change the code without worrying about breaking existing functionalities. It gives you confidence to change existing code and improve the internal quality.

Stub Server

A stub server is commonly used in the development process. Here, we’ll use a tool called json-server . It’s a very lightweight and easy-to-get-started node package.

Async Request in Application

Back to the application folder: bookish-react. In order to send a request and get data, we need an HTTP client. In this case, we will use axios.

You probably noticed that while we were at it, we refactored the App component to be a functional component, rather than a class component. This allows us to use the react-hooks APIs: useState and useEffect. The useState is analogous to the this.setState API, while useEffect is used for side effects such as setTimeout or async remote calls. In the callback, we define an effect that sends an async call to localhost:8080/books, and once the data is fetched, setBooks will be called with that data, and finally BookList will be called with books from the state.

You can see some output in the console from the stub server when the books API is reached when we run our application now (Figure 5-2).

Setup and Teardown

Let’s take a closer look at our code and tests. As you can see, an implicit assumption here is that the tests know that the implementation will return two books. The problem with this assumption is that it makes the tests a little mysterious: Why we are expecting expect(books.length).toEqual(2), why not 3? And why are those two books Refactoring and Domain-Driven Design? That kind of assumption should be avoided or should be clearly explained somewhere in the tests.

One way to do this is to create some fixture data that will be set before each test and cleaned up after each test finishes.

The json-server provides a programmatic way to do it. We can define the behaviors of the stub server with some code.

Refactor First

The purpose seems clear for now, but if we want to add more states, the responsibility might be mixed.

Define a React Hook

Looks pretty cool, right? The only parameter required by useRemoteService is the default value for BookList to render. The code is nice and clean now, and most importantly, the functional tests are still passing.

Unit Test with React-Testing-Library

Test Error State

To test the network error case, and you can see now all the tests are passing in Figure 5-3

it('error', () => {

  const props = {

    error: true

  };

  const {container} = render(<BookList {...props} />);

   const content = container.querySelector('p');

expect(content.innerHTML).toContain('Error');

})

Test Expected Data

Finally, we can add a happy path to make sure our component renders in the success scenario:

it('render books', () => {

  const props = {

    books: [

      { 'name': 'Refactoring', 'id': 1 },

      { 'name': 'Domain-driven design', 'id': 2 },

    ]

  };

  const { container } = render(<BookList {...props} />);

  const titles = [...container.querySelectorAll('h2')].map(x => x.innerHTML);

  expect(titles).toEqual(['Refactoring', 'Domain-driven design']);

})

You may be wondering if this is a duplication – haven’t we already tested this case in the Acceptance test? Well, yes and no. The cases in the unit tests can be used as documentation; it specifies what arguments the component requires, field names, and types. For example, in the props, we explicitly show that BookList requires an object with a books field, which is an array.

When running the tests, we will see a warning in the console:

  console.error node_modules/react/cjs/react.development.js:172

    Warning: Each child in a list should have a unique 'key' prop.

    Check the render method of "BookList." See https://fb.me/react-warning-keys for more information.

        in div (at BookList.jsx:14)

        in BookList (at BookList.test.jsx:32)

This is telling us that when rendering a list, React requires a unique key for each of the items, such as id. We can quickly fix it by adding a key for each item in the loop. In our case, as each book has a unique ISBN (the International Standard Book Number), we can use it in the stub server. Now, our final version of BookList looks like this:

import React from 'react';

const BookList = ({loading, error, books}) => {

  if(loading) {

    return <p>Loading...</p>

  }

  if(error) {

    return <p>Error...</p>

  }

  return <div data-test='book-list'>

    {

      books.map(book => (<div className='book-item' key={book.id}>

        <h2 className='title'>{book.name}</h2>

      </div>))

    }

  </div>;

}

export default BookList;

All unit tests are passing (Figure 5-4), great!

Summary

Sometimes, we may find that it’s complicated to write tests for code: there may be a lot of external dependencies. In this case, we need to refactor first, extract the dependencies out, and then add tests.

Link to Detail Page

Verify Book Title on Detail Page

That checks the page has a .book-title section, and its content is Refactoring. The test fails again; let’s fix it by adding client-side routing to our application.

As you can see, there is a page navigation here: the user will be able to jump to the detail page when clicking a button. That means we need some mechanism to maintain the router.

Front-End Routing

With those routes, when the user accesses root path /, the component BookListContainer will be rendered. When /books/123 is visited, BookDetailContainer will be displayed.

BookDetailContainer Component

Finally, we need to create a new file BookDetailContainer.js . It will be pretty similar to the first version of BookListContainer.js, except that the id of the book will be passed through react-router as match.params.id. Once we have the book id, we can send an HTTP request to load the book details:

```js BookDetailContainer.js

import React, {useEffect, useState} from ‘react’

import axios from ‘axios’

const BookDetailContainer = ({match}) => { const [id, _] = useState(match.params.id); const [book, setBook] = useState({});

useEffect(() => { const fetchBook = async () => { const book = await axios.get(http://localhost:8080/books/${id}); setBook(book.data); };

fetchBook();

}, [id]);

return (

<h2 className='book-title'>{book.name}</h2>

) }

export default BookDetailContainer ```

Great, the functional tests are now passing (Figure 6-1).

Refactor

Book Detail Page

File Structure

Our file structure is quite flat – there is no hierarchy at all as all the files are just there, in one folder. That is a code smell. It makes it very difficult to find what we’re looking for. Let’s restructure.

There are multiple ways to split an application into modules and organize them. I have found splitting the application by feature makes the most sense to me after having tried all of the different combinations across various projects.

Using Grid System

It may seem a little like a lot, but these are really just markup – think about the HTML tags that fit our application.

Making Styles for Components

In order to do this, we need to use Material-UI’s makeStyles function which will link a stylesheet with a function component using the hook pattern (Figure 6-4).

const useStyles = makeStyles(theme => ({

  root: {

    flexGrow: 1,

  },

  paper: {

    padding: theme.spacing(2),

    textAlign: 'center',

    color: theme.palette.text.secondary,

  },

  name: {

    maxHeight: 30,

    overflow: 'hidden',

    textOverflow: 'ellipsis',

  },

  description: {

    maxHeight: 40,

    overflow: 'hidden',

    textOverflow: 'ellipsis',

  }

}));

A Failing Test with undefined

Then our test failed again (Figure 6-5).

That way we separate rendering and computing, which can lead to better testability and readability.

One Step Further

We are using jest.fn() to create a spy object that can record the trace of invocations. We use userEvent.type API to simulate a change event with domain as it’s the payload. We can then expect that onChange method has been called.

What Have We Done?

Three Principles of Redux

In the Redux world, all state is stored inside a single global data source. At any given time, this data source can be mapped to the view. When changes occur – for example, a user clicks a button, a timeout occurs, or a back-end async message arrives – an action will be created, in the form of an object describing what happened.

Actions are just payloads of information in the form of JavaScript objects that transfer information from our application to our store of state.

Once created, the action will go through a pure function called a reducer. The reducer will specify how the application state will change in response to the action, and that may trigger another re-render of the view. It takes in the previous state and the action and returns the new state. Figure 8-2 demonstrates the process clearly.

Thanks to the virtual dom mechanism provided by React, the UI will re-render with minimal effort.

Environment Set Up

Start from Action

In redux, action is a payload of information that sends data from your application to the store. It’s similar to events in other GUI applications. To apply this information to the store, you will have to dispatch (send) it.

action is an excellent entry point – it will make us consider the way that the components interact with each other and how each component interacts with the outside world.

Take BookListContainer, for example. We expect that it has the ability to set the keyword for searching.

This test asserts that when a search term is provided to the setSearchTerm action creator, the action will be created.

The action creator, as the name suggests, will create an action and normally will be binded with events from user interaction (mouse click, keyboard).

Actions have a type property that signal the type of action being performed, but other than that, the structure of the action object is up to us to define.

setSearchTerm takes in a search term, and returns an action of type SET_SEARCH_TERM, and whatever string was provided as the search term.

A piece of cake!

Note that while we are saving term in the store here, we don’t have to. It’s really up to you – the developer – to decide where to put those statuses. A good rule of thumb is to keep the store as simple and flat as possible. Any data that could be computed by other fields should not be placed there, and in most cases, internal state that no one else cares about should stay inside the component as well.

Test the Container

If you take a close look at BookListContainer , you will find it’s relatively difficult to test at the unit-test level. By saying that, I mean it depends on a few outside components like actions and even the network.

Here, we’re using the same store as in the real application. Of course, you can define some static store for testing as well.

As we’ve already covered this function in the cypress tests, you may be wondering what the point is of testing that functionality here. This is because we can test far more cases here with faster feedback. For example, if we want to make sure that when network failure occurs, we should see an error message on the page. Since the reasons for network failure are many and vary, testing each of those possibilities in slow cypress tests is not ideal.

By using axios-mock-adapter, you can easily simulate different network issues, or even cases where the data shape changes and how the component will handle it.

Fetch Book Detail

We have now successfully migrated to redux, and the test coverage looks like Figure 8-3.

That’s a really great achievement.

Start with an Empty List

Rendering a Static List

Here, we are demonstrating how to use the component from the outside (pass in an array of reviews, each of which has fields for name date, and content). It would be possible for other programmers to reuse our component without looking into our implementation.

Use the Review Component

For our first integration, let’s put the ReviewList in BookDetail. You probably know by now, we’re going to implement the test first.

Fulfill a Book Review Form

We can generate some static data to display in the BookDetail component, but it would be better if we can show some real data from the end user. We need a simple form for the user to communicate their point of view about the book. For now, we can provide two input boxes and a submit button. The first input is for the user’s name (or email address) and the second (a textarea) is used for the review content.

Action in Redux

json-server Customization

We’ve been using json-server to simplify the back-end API work for us. We need to customize it a little more to fit our new requirement. We expect that review is a sub-resource of a book, and that allows us to access all the reviews belonging to a particular book by requesting /books/1/reviews.

Then, whenever you access /books/1, it returns all the reviews along with the response.

Great work! Also, when we POST some data to http://localhost:8080/books/1/reviews, it will create a review under the book with id 1.

Now, we can create the review via the form. Note the stub server returns a 201 to indicate the review has been accepted (Figure 9-2).

Note here we add dispatch (fetchABook(id)) in the success callback. It refreshes the reviews for us. However, when you rerun the test, the creation of review will fail because we didn’t clean up after the test case execution.

Now, we don’t have to worry about a single failing test causing issues for another test.

Refactoring

And now the ReviewForm should be something like Figure 9-3.

Save the Review – Action

Note that we are reusing the SAVE_BOOK_REVIEW type here.

Integration

We use the useDispatch React hook to generate a dispatch from react-redux, and then use it to trigger a real action (Figure 9-4).

Summary

Fantastic, we’ve finished the whole Review section. That’s a relatively big component that has a list of Reviews, and in each section, we allow a user to add a new Review as well as editing existing ones.

Along the way, we tried a different approach to TDD – writing unit tests to drive out a detached Component first, and then detached actions, and finally an integration test that can make sure we connect them together.

Install and Config Cucumber Plugin

Cool, that’s all for the configuration. We can now start to write some feature tests in plain English.

File Structure

So at runtime, cypress-cucumber-preprocessor will load *.feature and try to execute them.

The First Feature Specification

Note the indention and keywords like Scenario, Given, When, and Then. Some of the earlier text is just for human beings. For example, the interpreter isn’t interested in the As a <role>, I want to <do something>, So that<business value> section. That part is like comments in any other programming language and won’t be picked up by cucumber. Instead, it will start right from the Scenario section beneath.

Define the Steps

All the sentences in a Scenario section are called a step definition and need to be translated into executable code in some way behind the scenes. cucumber uses regular expressions to match the sentence. It tries to extract some parameter from the sentence, which is then passed into the step function.

Interpret Sentences by Step Definition

We can define regular expressions with Given, When, and Then functions from cypress-cucumber-preprocessor and do something interesting in those functions.

For example:

import {checkAppTitle, gotoApp} from '../../helpers';

import {Given, Then, When} from 'cypress-cucumber-preprocessor/steps';

Given(`I am a bookish user`, () => {

  //

});

When(`I open the list page`, () => {

  gotoApp();

});

Then(`I can see the title {string} is showing`, (title) => {

  checkAppTitle(title);

});

The parameters passed into Given, When, and Then functions are pretty similar; the first one is a regular expression, which is used to match a sentence in .feature files. The second is a similar regular expression, which returns a callback, which will be invoked once there is a match. If there are some patterns in the regular expression, the value will be extracted and passed to the callback (see the Then example). This is a simple but powerful mechanism that allows us to do some interesting work – including launching the browser and checking if particular elements are showing on the page.

Now let’s run npm run e2e (as you can see in Figure 10-1 below) to verify everything is correctly linked.

So, our Feature is interpreted correctly, and the parameters are extracted and passed to the method correspondingly. Note that we can reuse functions we extracted in the previous chapters like gotoApp() and checkAppTitle.

Book List

With every piece connected, we can now start to define a step definition with existing helper functions.

Searching

Reviews Page